[レポート]【ランチセッション】Amazon CloudSearch Deep Dive #AWSSummit

AWS Summit Tokyo 2015のTA-01: Tech Deep Dive by Amazon:「【ランチセッション】Amazon CloudSearch Deep Dive」のレポートです。

スピーカーはAmazon Data Services Japanの篠原英治氏です。

レポート

Amazon CloudSearchとは

SnapDishでCloudSearchが使われている。 SnapDishでウインナーで検索→CloudSearchで検索。 CloudSearchを使うことでサーバー運用の負担から解放された。 フルマネージドなクラウド型検索エンジン。簡単に導入できる。 多言語対応。34の言語。ヘブライ語なども対応している。 ヒットしたらハイライトしたり、サジェストしたり、便利な機能がたくさん。

CloudSearchの背景 Amazonの最下部の検索→サーチエンジン=A9と記載されている。 CloudSearchはA9がパロアルトで作っている。 スタンフォード大学が近い。

CloudSearchの使い方。例えば南北線の駅を検索する場合。 検索ドメインの作成 検索用のデータファイル(駅コード、駅名、路線)の作成 データファイルのアップロード データを自動認識してスキーマ定義を作成 日本語でのトークナイズの指定可能 Dynamic FIeld機能も使える マネージメントコンソール上ですぐに検索できる or検索ももちろん可能

Japanese Text Processing 形態素解析→日本語はスペースで区切られていないので解析の必要がある 名詞の辞書のメンテナンスが必要 →CloudSearchでは辞書のカスタマイズが可能 →APIから辞書登録もできる シノニム、類義語 ベニス、ベネチア、ヴェネチア、等 Aliasの設定ができる Group化も出来る Bi-gramでのIndexing Muttiple LanguagesでBi-gramでIndexingされる 2文字ずつ区切ってしまうので検索ノイズが発生 (例:東京都が京都でヒット) ノイズは発生するけど取りこぼしが少なくなる 形態素解析とBi-gramを組み合わせて使う CloudSearchではSourceFieldという機能がある 元フィールドからデータをコピーしてトークナイズする 形態素解析のフィールドからBi-gramのフィールドを作る →^(カレット)を使ってソート順を調整 形態素解析の結果を上に、Bi-gramのフィールドを下に表示したり、など スコア=tf-idf あるドキュメントによく出てきて、他のドキュメントにでてこない →このドキュメントでは重要性が高いと判断 Expressions 検索結果のチューニングに様々な手法が使える A/Bテスト マネージメントコンソール上でチューニング結果を比較しながら確認出来る

Field Typeのカスタマイズ dateやint、textなど、データによってTypeを変えられる nanapiのCloudSearch利用法→nanapi tech blogに記述がある Suggestions ひらがなやカタカナで検索→候補を表示 高可用性の強化→Multi-AZ対応 IAMによるアクセス制御可能 ユーザーやリソースによってきめ細やかな制御が可能

Inside Amazon CloudSearch

フルマネージド Auto Scaling + Auto Partitioning

Indexing データを保持している全てのノードにELB経由で均等にアップロード データを受け取ったノード→ファイルをS3に保存、メタ情報をDynamoDBに保存 ノードではアップデート処理とは非同期でUpdaterが動作 自Partition担当のIndexingデータがあればローカルのSolrに配置 S3とDynamoDBの組み合わせでフルマネージドの高い信頼性が確保できている

Query indexingと同様にELB経由で均等に割り振り リクエストを受け取ったノードがそれぞれのノードから検索(分散処理)

Auto Scaling 検索リクエストが大量に発生したらAuto Scalingするシンプルな仕組み

Auto Partitioning 最初はスケールアップしていく スケールアップするのでダウンタイムはない →切り替わり中はIndexing結果がすぐに反映されない場合がある 最大までスケールアップしたら、次はスケールアウト パーティションの分割処理はHadoop(EMR)で行っている ダウンタイムは無いが結果整合性モデルになる→一時的に取れない場合がある 検索ドメインの設定変更 →変更に伴う処理はEMRで行っている こちらもダウンタイム無し、結果整合性モデル 大量に初期データを投入する場合 →あらかじめ大きなインスタンスを多数並べることで、 短時間でIndexingを実行可能 インスタンスタイプとデータ量の目安は？ 扱うデータによって圧縮率が異なるので、保持量に差がある。一概には言えない。 やろうとするデータで試してみるのが一番簡単。 大量の検索リクエストに事前に備える(予測されるバーストトラフィック) 事前にレプリケーションカウントを上げておくことで準備可能 インスタンスタイプとスループットの目安 →これも扱うデータによってスループットが変わってくる

2015年2月からm3インスタンスが利用可能に →安く安定して動作するようになった

Amazon CloudSearch事例

爆速で導入→schoo リリースするまでに1週間程度だった フルマネージドの良さを活用→nanapi デフォルトのままでいい感じで使える 簡単に構築できちゃう、とにかく楽 大規模利用→Chatwork 5億件オーバー 導入時は大変だったがリリース後はほぼメンテナンスフリー データ量が増えても検索のレスポンスは落ちない Lancers、ごちクル、Smart/InSight、パソナキャリア、e.t.c.

さいごに

CloudSearchのバッググラウンドが聴けて非常に面白かったです！